Identification and privacy in the World Wide Web

ABSTRACT

A method for obtaining a service on a data communications network, the method includes enrolling with an authority and using the enrollment results to obtain a service from a service provider. The enrolling creates enrollment results that include user data. The service provider is capable of communicating with the authority to verify the enrollment results

FIELD OF THE INVENTION

[0001] The present invention relates to the field of computer science.More particularly, the present invention relates to a system and methodfor managing identification in the World Wide Web.

BACKGROUND OF THE INVENTION

[0002] The advent of the World Wide Web (WWW) has made much moreinformation available for use by anyone with a computer having anInternet connection. Unfortunately, current methods make it relativelyeasy to identify a particular user with specific data about the user,thus raising privacy concerns.

[0003] One problem with identification and privacy on the Web concernshow Web browsers obtain user data. Typically, Web browsers obtain userdata from one or more cookies stored on a local hard disk. The cookiesmay contain sensitive user information, FIG. 1A is a flow diagram thatillustrates a typical method for obtaining user information from acookie. At 100, a Web browser accesses a Web site that uses a cookie. At105, a determination is made regarding whether a cookie is present onthe user computer's local disk. If a cookie is not present, at 110 thebrowser generates a cookie with the Web server Universal ResourceLocator (URL) and Web server-provided user data. If a cookie is present,at 115 the browser uses the cookie on the user computer's local disk.

[0004]FIG. 1B is a block diagram that illustrates a cookie. A cookie 120includes a server identifier and user data. The user data containsinformation about a user, such as the user's name and address.

[0005] Unfortunately, the privacy afforded by this approach is lowbecause it is relatively easy to determine the identity of the userassociated with the user data merely by examining the cookie contents.

[0006] Another problem with identification and privacy on the Webconcerns user authentication. User authentication on the Web istypically accomplished using a username and password. FIG. 2 is a flowdiagram that illustrates a typical method for performing userauthentication using a username and a password. At 200, a user visits aservice provider Web site. At 205, the service provider Web siteauthenticates the user based on a static username and password. Thisform of user authentication typically includes filling out a form fordata that is deemed relevant for the services being rendered on the Web.At 210, a determination is made regarding whether the userauthentication was successful. If the user authentication wasunsuccessful, service is refused at 215. If the user authentication wassuccessful, service is provided at 220. The privacy protection andsecurity afforded by this approach are low.

[0007] Furthermore, the accuracy and appropriateness of the datagathered on the forms is not guaranteed. For example, if the serviceprovider form completed by the user prompts for a drivers licensenumber, the service provider typically does not determine whether thenumber entered by the user is appropriate for the service request (e.g.entering a fishing license number when prompted for a drivers license isinappropriate). And the service provider typically does not determinewhether the entered drivers license actually belongs to the person whoentered the number.

[0008]FIG. 3 illustrates how such user authentication problems areaddressed using a “bricks and mortar” approach. FIG. 3 is a flow diagramthat illustrates a typical method for paying for goods and services inperson. At 300, a purchaser writes a check to pay for goods or services.At 305, a vendor requires credentials that will be appropriate for themethod of user authentication needed to accept payment. Examples of suchcredentials include a driver's license and an ATM card. The userauthentication provides a level of trust regarding the identity of thepurchaser. Different levels of user authentication are affordeddifferent types of transactions. For example, if the purchaser attemptsto buy a relatively inexpensive item, the vendor might accept a checkfor payment without user authentication. If the purchaser attempts tobuy a moderately priced item, the vendor might require one form ofidentification such as a driver's license. If the purchaser attempts tobuy a relatively expensive item, the vendor might require additionalforms of identification. Once the purchaser provides the required formsof user authentication (310), the vendor uses the required forms of userauthentication to verify the truthfulness, accuracy and completeness ofthe credentials (315). If the vendor cannot satisfactorily verify thecredentials, the transaction is rejected at 325. If the credentials aresatisfactorily verified, the sale is completed at 330.

[0009]FIG. 4 is a block diagram that illustrates maintaininguser-specific information on the World Wide Web. Each Internet user400-425 accesses Web sites of service providers via a service providerWeb server (435-460). Each Web server 435-460 authenticates the user byprompting for a username and a password. Each Web server 435-460 alsomaintains a separate set of user data for each (username, password)combination. The user data contains information about each user. Forexample, one Web site may store the zip code associated with theusername so that the current weather at that zip code is presentedwhenever the user logs in to the Web site. Another Web site mightmaintain a list of items purchased at the Web site, so that informationabout similar products can be displayed when the user visits the siteagain.

[0010] Maintaining separate user authentication schemes for each Website means that users must remember their username and password for eachsite. Oftentimes, an individual will use the same username and passwordfor each Web site. Thus, once the users' username and password for oneweb site are known, the same username and password can be used to accessinformation for the same user at another Web site. Moreover, individualsoften base their username and password on personal information such associal security number or birthday. This makes passwords vulnerable toattack by hackers.

[0011]FIG. 5 is a block diagram that illustrates a centralized userauthentication system. At 540 a user accesses a server access portal505. At 545, the service access portal 505 collects user authenticationdata. If the user has already enrolled, the user is prompted for ausername and password and ticket generator 520 interfaces with a userauthentication database 524 to authenticate the user based on theusername and password. Ticket generator 520 may be a Kerberos™ ticketgenerator. Ticket generator 520 interfaces with the user authenticationdatabase 525 to perform user authentication and to generate a userauthentication token at 565. If the user has not yet enrolled, the useris prompted for user data and a chosen password at 545 and thisinformation is sent to a user data generator 530. User data generator530 interfaces with a user database 535 to store the user data. Userdata generator 530 also interfaces with the user authentication database525 to provide user authentication information for the user. At 560,user data generator 530 interfaces with ticket generator 520 to generatea user authentication token. At 565 the user authentication token isreturned to the service provider 505.

[0012] At 570, the user authentication token is returned to the user500. The service provider 505 uses the user authentication token as acookie or session identifier in subsequent communications (575, 580)between the user and the service provider. These communications mayinclude requests 585 for user data stored in user database 535. Suchrequests 585 are received by user data retriever 515. Data retriever 515retrieves the user data from user database 535 and returns the user dataat 590.

[0013] Unfortunately, the service provider using this mechanism is asingle point of control. A user has no control over where and when userdata is obtained and where and when the service provider uses the userdata. All user data is in the open once the user has identified himself.

[0014]FIG. 6 is a block diagram that illustrates a mechanism thatprovides a single logon for access to multiple Web sites. Globalauthenticator 305 authenticates a user 600-625 by prompting for a(username, password) combination. Once the user 600-625 isauthenticated, the user can access each member Web site 635-660 withouthaving to sign on to each particular Web site 635-660. Globalauthenticator 630 also maintains a profile for each username in globalcustomer database 665.

[0015] As shown in FIG. 6, a user may visit multiple member Web sitesonce logged in via global authenticator 630. Thus, global customerdatabase 665 must include information for a user that is relevant to allsites visited. For example, if a user visits a financial Web site and amedical plan Web site, global customer database 665 will include medicalinformation as well as financial information. Moreover, globalauthenticator 630 may be configured to monitor or track an individual'sWeb activity such as the Web sites visited. Commingling potentiallyinappropriate data and the ability to monitor Web activity raise privacyconcerns.

[0016] An additional problem with the using the World Wide Web is thelack of ways to create a trail of what a service provider accepts asvalid user authentication. A user either logs in using a username andpassword that any person or program could have entered and is grantedaccess to multiple services indefinitely, or the user enters the wrongusername and password and gets nothing.

[0017] Accordingly, what is needed is a solution that protects privacyin a system where information about a user is required to deliverservices. A further need exists for such a solution that enables serviceproviders to exchange information about a person without revealinginappropriate or unnecessary information. A further need exists for sucha solution that manages user transactions on an open network such as theInternet while maintaining privacy. A further need exists for such asolution that manages trust in user data and creates a trail ofassessments of the trust and the process of how the assessments weremade. A farther need exists for such a solution that protects user datastored in cookies.

BRIEF DESCRIPTION OF THE INVENTION

[0018] A method for managing identification in a data communicationsnetwork includes receiving a user-controlled secure storage device andenrolling the user with an authority network site. The enrollingincludes providing information requested by the authority network site.The method also includes receiving user data in response to theenrolling, storing the user data in the user-controlled secure storagedevice, enabling the user-controlled secure storage device to releasethe user data and using the user data at a service provider network siteto obtain a service.

[0019] According to another aspect, a method for enhanced privacyprotection in identification in a data communications network includesenrolling for a service on the data communications network, receiving arandomized identifier (ID) in response to the enrolling, storing therandomized ID and using the randomized ID to obtain services on the datacommunications network. An apparatus for obtaining a service on a datacommunications network includes an enrollment authority configured toaccept an enrollment request. The enrollment authority is furtherconfigured to return enrollment results in response to the enrollmentrequest. The enrollment results include user data and the enrollmentresults may be used obtaining a service from a service provider.

[0020] According to another aspect, a method for enhanced quality ofidentification in a data communications network includes obtaining auser identifier that includes an identification server ID and anidentification randomized ID. The identification server ID identifies anidentification server peer group. The identification server peer groupincludes at least one server that maintains a mapping between anidentification randomized ID and a user authentication peer groupcapable of authenticating a user associated with a particular randomizedID, and a mapping between the identification randomized ID and userinformation. The method also includes requesting authorization of theuser by presenting the user identifier to a corresponding identificationserver peer group. Each server in the identification server peer groupis configured to search for one or more matching entries including therandomized ID.

[0021] According to another aspect, a method for controlling user accessto distributed resources on a data communications network includesreceiving a resource request. The request includes a rights keycredential that includes at least one key to provide access to aresource on the data communications network. The rights key credentialalso includes a resource identifier that includes a resource server peergroup ID and a randomized ID. The resource server peer group IDidentifies a resource server peer group. The resource server peer groupincludes at least one server that maintains a mapping between arandomized ID and the at least one key. The method also includesproviding access to the resource using the at least one key.

[0022] According to another aspect, a method for browsing a datacommunications network includes requesting user data from auser-controlled secure device if a network site that requires the userdata is accessed. The request is performed prior to requesting the userdata from another device. The method also includes sending the user datato a network server associated with the network site if the user data isreceived from the user-controlled secure device. According to anotheraspect, a method for servicing data communications network informationunits includes receiving user data associated with a network site, usingthe user data if the user data includes static user data andreconstructing the user data before using the user data if the user dataincludes dynamic user data.

[0023] According to another aspect, an apparatus for browsing a datacommunications network includes a network browser configured to requestuser data from a user-controlled secure device if a network site thatrequires the user data is accessed. The request occurs prior torequesting the user data from another device. The network browser isfurther configured to send the user data to a network server associatedwith the network site if the user data is received from theuser-controlled secure device.

[0024] According to another aspect, an apparatus for browsing a datacommunications network includes a smart card configured to receive arequest for user data. The smart card is further configured to returnthe user data if the user data is found and if returning user data forthe request is enabled and if the user data includes static user data.The smart card is further configured to reconfigure the user data if theuser data is found and if returning user data for the request is enabledand if the user data includes dynamic user data.

[0025] According to another aspect, an apparatus for servicing datacommunications network information units includes a network serverconfigured to receive user data associated with a network site. Thenetwork server is further configured to use the user data if the userdata includes static user data. The network server is further configuredto reconstruct the user data before using the user data if the user dataincludes dynamic user data.

[0026] According to another aspect, a method for obtaining a service ona data communications network, the method includes enrolling with anauthority and using the enrollment results to obtain a service from aservice provider. The enrolling creates enrollment results that includeuser data. The service provider is capable of communicating with theauthority to verify the enrollment results.

[0027] According to another aspect, an apparatus for obtaining a serviceon a data communications network includes an enrollment authorityconfigured to accept an enrollment request. The enrollment authority isfurther configured to return enrollment results in response to theenrollment request. The enrollment results include user data, for use inobtaining a service from a service provider. According to anotheraspect, an apparatus for obtaining a service on a data communicationsnetwork, the apparatus includes a service provider configured to accepta service request and enrollment results obtained from an enrollmentauthority. The service provider is capable of communicating with theauthority to verify the enrollment results and the service provider isconfigured to provide the service based upon the enrollment results anda response from the enrollment authority.

[0028] According to another aspect, a method for protecting privacy on adata communications network includes receiving a user identifier andspecific user data associated with the user identifier. The specificuser data includes data about a network user. The method also includescreating generalized user data based on the specific user data andassociating the generalized user data with the user identifier. Themethod also includes returning the user identifier and the generalizeduser data. According to another aspect, a method for protecting privacyon a data communications network, the method includes storing user logoninformation for at least one service provider server on auser-controlled secure device. The at least one service provider serverincludes at least one network server that is capable of providing aservice to a user. The method also includes logging on to the device,providing access to the at least one service provider server.

BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The accompanying drawings, which are incorporated into andconstitute a part of this specification, illustrate one or moreembodiments of the present invention and, together with the detaileddescription, serve to explain the principles and implementations of theinvention.

[0030] In the drawings:

[0031]FIG. 1A is a flow diagram that illustrates a typical method forobtaining user information from a cookie.

[0032]FIG. 1B is a block diagram that illustrates a cookie.

[0033]FIG. 2 is a flow diagram that illustrates a typical method forperforming user authentication using a username and a password.

[0034]FIG. 3 is a flow diagram that illustrates a typical method forpaying for goods and services in person.

[0035]FIG. 4 is a block diagram that illustrates maintaininguser-specific information on the World Wide Web.

[0036]FIG. 5 is a block diagram that illustrates a centralized userauthentication system.

[0037]FIG. 6 is a block diagram that illustrates a mechanism thatprovides a single logon for access to multiple Web sites.

[0038]FIG. 7 is a block diagram that illustrates conducting securetransactions on the World Wide Web using user data authenticated by anauthority in accordance with one embodiment of the present invention.

[0039]FIG. 8 is a flow diagram that illustrates a method for conductingsecure transactions on the World Wide Web using user data authenticatedby an authority in accordance with one embodiment of the presentinvention.

[0040]FIG. 9A is a block diagram that illustrates a credential inaccordance with one embodiment of the present invention.

[0041]FIG. 9B is a block diagram that illustrates a credential that usesa cryptogram as an identifier in accordance with one embodiment of thepresent invention.

[0042]FIG. 10 is a flow diagram that illustrates a method for generatinga credential in accordance with one embodiment of the present invention.

[0043]FIG. 11 is a flow diagram that illustrates a method for processinga credential in accordance with one embodiment of the present invention.

[0044]FIG. 12 is a flow diagram that illustrates a method for applyingcredential evaluation policies in accordance with one embodiment of thepresent invention.

[0045]FIG. 13 is a flow diagram that illustrates a method for assessingcredential data in accordance with one embodiment of the presentinvention.

[0046]FIG. 14 is a flow diagram that illustrates a method for performinguser authentication in accordance with one embodiment of the presentinvention.

[0047]FIG. 15 is a flow diagram that illustrates a method for using acredential to obtain services in accordance with one embodiment of thepresent invention.

[0048]FIG. 16 is a block diagram that illustrates assigning multipleidentities to an individual in accordance with one embodiment of thepresent invention.

[0049]FIG. 17 is a block diagram that illustrates assigning multiplesets of user data for identities in accordance with one embodiment ofthe present invention.

[0050]FIG. 18 is a block diagram that illustrates conductingtransactions between multiple parties on an open network whilemaintaining privacy in accordance with one embodiment of the presentinvention.

[0051]FIG. 19 is a flow diagram that illustrates a method for conductingtransactions between multiple parties on an open network whilemaintaining privacy in accordance with one embodiment of the presentinvention.

[0052]FIG. 20 is a flow diagram that illustrates a method for using userdata stored on a user-controlled device to obtain services in accordancewith one embodiment of the present invention.

[0053]FIG. 21 is a flow diagram that illustrates a method for providinga service in accordance with one embodiment of the present invention.

[0054]FIG. 22 is a flow diagram that illustrates a method for providinga service in accordance with user data in accordance with one embodimentof the present invention.

[0055]FIG. 23 is a flow diagram that illustrates a method for performingpayment authorization using payment data from a secure device inaccordance with one embodiment of the present invention.

[0056]FIG. 24 is a block diagram that illustrates assigning multiplecredentials for identities in accordance with one embodiment of thepresent invention.

[0057]FIG. 25 is a block diagram that illustrates conductingtransactions between multiple parties using service credentials on anopen network while maintaining privacy in accordance with one embodimentof the present invention.

[0058]FIG. 26 is a flow diagram that illustrates a method for conductingtransactions between multiple parties using service credentials on anopen network while maintaining privacy in accordance with one embodimentof the present invention.

[0059]FIG. 27 is a block diagram that illustrates using nestedcredentials in accordance with one embodiment of the present invention.

[0060]FIG. 28A is a flow diagram that illustrates a method forconducting transactions between multiple parties using servicecredentials on an open network while maintaining privacy in accordancewith one embodiment of the present invention.

[0061]FIG. 28B is a flow diagram that illustrates a method for using aservice credential stored on a user-controlled device to obtain servicesin accordance with one embodiment of the present invention.

[0062]FIG. 29 is a flow diagram that illustrates a method for providinga service in accordance with one embodiment of the present invention.

[0063]FIG. 30A is a flow diagram that illustrates a method forperforming a payment authorization using nested payment credentialsextracted from a service credential in accordance with one embodiment ofthe present invention.

[0064]FIG. 30B is a block diagram that illustrates assigning multiplesets of user data for identities in accordance with one embodiment ofthe present invention.

[0065]FIG. 31 is a block diagram that illustrates conductingtransactions between multiple parties using a smart card on an opennetwork while maintaining privacy in accordance with one embodiment ofthe present invention.

[0066]FIG. 32 is a block diagram that illustrates development of anapplet as may be used to provide a secure user access control functionfor a resource-constrained device such as a smart card.

[0067]FIG. 33A is a block diagram that illustrates a computer connectedto the Internet and equipped with a card reader for receiving a smartcard.

[0068]FIG. 33B is a block diagram that illustrates assigning varioustypes of user data for identities in accordance with one embodiment ofthe present invention.

[0069]FIG. 34 is a block diagram that illustrates an identifier inaccordance with one embodiment of the present invention.

[0070]FIG. 35 is a block diagram that illustrates using federatedidentification servers and federated user authentication servers using arandomized user identifier to gain access to a service while maintainingprivacy in accordance with one embodiment of the present invention.

[0071]FIG. 36 is a flow diagram that illustrates a method for usingfederated identification servers and federated user authenticationservers using a randomized user identifier to gain access to a servicewhile maintaining privacy in accordance with one embodiment of thepresent invention.

[0072]FIG. 37 is a flow diagram that illustrates a method for usingfederated identification servers and federated user authenticationservers using a randomized user identifier to gain access to a servicewhile maintaining privacy in accordance with one embodiment of thepresent invention.

[0073]FIG. 38 is a block diagram that illustrates enrolling with anidentity server in accordance with one embodiment of the presentinvention.

[0074]FIG. 39 is a block diagram that illustrates possible credentialtypes in accordance with one embodiment of the present invention.

[0075]FIG. 40 is a block diagram that illustrates using a randomizedidentifier for access to distributed resources while maintaining privacyin accordance with one embodiment of the present invention.

[0076]FIG. 41 is a flow diagram that illustrates a method for presentinga matching entry or entries from an identity server federation to a userauthentication server federation to determine a single valid user dataentry in accordance with one embodiment of the present invention.

[0077]FIG. 42A is a block diagram that illustrates data stored in aresource server in accordance with one embodiment of the presentinvention.

[0078]FIG. 42B is a block diagram that illustrates data stored in aresource server in accordance with one embodiment of the presentinvention.

[0079]FIG. 43A is a block diagram that illustrates obtaining a resourcefrom a resource server in response to a resource request including a setof rights keys in accordance with one embodiment of the presentinvention.

[0080]FIG. 43B is a block diagram that illustrates obtaining a resourcefrom a resource server in response to a resource request including a setof rights keys and a reference to a delivery protection mechanism andoptionally a target device in accordance with one embodiment of thepresent invention.

[0081]FIG. 43C is a block diagram that illustrates a rights keycredential in accordance with one embodiment of the present invention.

[0082]FIG. 44 is a flow diagram that illustrates a method for obtainingaccess to a resource in accordance with one embodiment of the presentinvention.

[0083]FIG. 45 is a flow diagram that illustrates a method for obtainingaccess to a resource requiring multiple keys in accordance with oneembodiment of the present invention.

[0084]FIG. 46A is a block diagram that illustrates a Universal ResourceLocator (URL) that includes a rights key credential to access a specifickind of resource stored on a server in a resource server peer group inaccordance with one embodiment of the present invention.

[0085]FIG. 46B is a block diagram that illustrates a Hypertext TransferProtocol (HTTP) message that includes rights key credential data inaccordance with one embodiment of the present invention.

[0086]FIG. 46C is a block diagram that illustrates a smart card thatincludes a rights management applet in accordance with one embodiment ofthe present invention.

[0087]FIG. 46D is a block diagram that illustrates dynamic aggregationof user data in accordance with one embodiment of the present invention.

[0088]FIG. 47 is a flow diagram that illustrates a method for dynamicaggregation of user data in accordance with one embodiment of thepresent invention.

[0089]FIG. 48 is a flow diagram that illustrates a method for staticaggregation of user data in accordance with one embodiment of thepresent invention.

[0090]FIG. 49 is a block diagram that illustrates using a smart card tosecurely store and reconfigure cookies in accordance with one embodimentof the present invention.

[0091]FIG. 50 is a block diagram that illustrates using a smart card tosecurely store and reconfigure cookies in accordance with one embodimentof the present invention.

[0092]FIG. 51 is a flow diagram that illustrates a method for browsingthe World Wide Web (WWW) in accordance with one embodiment of thepresent invention.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

[0093] Embodiments of the present invention are described herein in thecontext of a method and apparatus for identification and privacy in theWorld Wide Web. Those of ordinary skill in the art will realize that thefollowing detailed description of the present invention is illustrativeonly and is not intended to be in any way limiting. Other embodiments ofthe present invention will readily suggest themselves to such skilledpersons having the benefit of this disclosure. Reference will now bemade in detail to implementations of the present invention asillustrated in the accompanying drawings. The same reference indicatorswill be used throughout the drawings and the following detaileddescription to refer to the same or like parts.

[0094] In the interest of clarity, not all of the routine features ofthe implementations described herein are shown and described. It will,of course, be appreciated that in the development of any such actualimplementation, numerous implementation-specific decisions must be madein order to achieve the developer's specific goals, such as compliancewith application- and business-related constraints, and that thesespecific goals will vary from one implementation to another and from onedeveloper to another. Moreover, it will be appreciated that such adevelopment effort might be complex and time-consuming, but wouldnevertheless be a routine undertaking of engineering for those ofordinary skill in the art having the benefit of this disclosure.

[0095] In the context of the present invention, the term “network”includes local area networks, wide area networks, the Internet, cabletelevision systems, telephone systems, wireless telecommunicationssystems, fiber optic networks, ATM networks, frame relay networks,satellite communications systems, and the like. Such networks are wellknown in the art and consequently are not further described here.

[0096] Embodiments of the present invention are described with referenceto the World Wide Web. Any data communications network may be configuredlike the World Wide Web.

[0097] In accordance with one embodiment of the present invention, thecomponents, processes and/or data structures may be implemented using Cor C++ programs running on high performance computers (such as anEnterprise 2000™ server running Sun Solaris™ as its operating system.The Enterprise 2000™ server and Sun Solaris™ operating system areproducts available from Sun Microsystems, Inc. of Mountain View,Calif.). Different implementations may be used and may include othertypes of operating systems, computing platforms, computer programs,firmware, computer languages and/or general-purpose machines. Inaddition, those of ordinary skill in the art will recognize that devicesof a less general purpose nature, such as hardwired devices, fieldprogrammable gate arrays (FPGAs), application specific integratedcircuits (ASICs), or the like, may also be used without departing fromthe scope and spirit of the inventive concepts disclosed herein.

[0098] Turning now to FIG. 7, a block diagram that illustratesconducting secure transactions on the World Wide Web using user dataauthenticated by an authority in accordance with one embodiment of thepresent invention is presented. Three entities are represented: acustomer or user 700, an authority 705 and a service provider 715. User700 represents an entity that requests and receives a service from aservice provider. Service provider 715 represents an entity thatprovides a service. Authority 705 represents an entity thatauthenticates credentials or other user data to assert an indication ofa quality metric or level of truthfulness, accuracy and completeness ofthe credential or other user data.

[0099] The issuer of a credential performs data authentication of thecredential. A credential is a certificate presented to a serviceprovider as an indication of what the presenter is entitled, along witha service request.

[0100] According to embodiments of the present invention, a user firstenrolls with an authority and receives an authenticated credential inreturn. The user then presents the credential and a service request to aservice provider. Accepting a credential is not unconditional. Theservice provider examines the request and the credential and eitherdenies service or grants the service. In more detail, at 720 a user 700communicates with an authority 705 to issue a credential request. Therequest may include associated parameters and data. The associatedparameters and data may relate to, by way of example, the identity of auser authentication server 710 capable of performing at least part ofthe user authentication required for issuance of the requestedcredential. The request may also include supporting credentials. Theauthority 705 authenticates the credential or credentials to assert anindication of a quality metric or indication of truthfulness, accuracyand completeness of the credential or credentials. The authority 705 maycooperate with a secondary authority 710 in performing userauthentication. At 725, the authority returns an authenticatedcredential to the user 700.

[0101] Using a credential to obtain a service begins with a servicerequest. As indicated by reference numeral 735, the user 700communicates with a service provider 715 to issue a service request. Therequest may include credentials and associated credential parameters anddata. The service provider 715 assesses the credential request andsupporting information. The service provider 715 may cooperate with anauthority 705 to perform dynamic credential authentication (740, 745).The authority 705 may also cooperate with a secondary authority 710 inperforming user authentication. At 750, the service provider providesthe requested service.

[0102] Turning now to FIG. 8, a flow diagram that illustrates a methodfor conducting secure transactions on the World Wide Web using user dataauthenticated by an authority in accordance with one embodiment of thepresent invention is presented. At 800 a credential is generated. Thecredential is created by presenting a credential request and supportingdata to an authority. The supporting data may include credentialscreated earlier by the same authority, or by another authority. Thecredentials may be non-digital as well. For example, a driver's licenseor birth certificate may be used. Depending upon the type ofauthentication required, the credentials may be all digital, allnon-digital or a combination of digital and non-digital credentials.

[0103] According to one embodiment of the present invention, acredential may be created with limitations placed on its use. Forexample, the credential may be created for one-time use, for use alimited number of times or for use at a specific location.

[0104] According to another embodiment of the present invention, thecredential may be stored on a Web server, smart card, personal digitalassistant (PDA), cell phone or the like.

[0105] Referring again to FIG. 8, at 805 a determination is maderegarding whether it is time to use the credential. An example of a timeto use the credential is when the credential is needed to obtain aservice. Once it is time to use the credential, at 810 the credential ora reference to the credential is presented to a service provider, whichcan then render a service. The service may be specified directly orindirectly by information contained in the credential. The serviceprovider may accept the credential data after performing acryptographical data authentication. At 815, a determination is maderegarding whether the credential is still valid. This process of using acredential to obtain a service continues until the credential is nolonger valid.

[0106]FIGS. 9A and 9B illustrate two credential data formats inaccordance with embodiments of the present invention. Referring to FIG.9A, credential 900 includes a credential identifier 910, a credentialcryptogram 915, a credential authority peer group ID 920, credentialparameters 925, credential data 930, sealed credential data 935 andnested credentials 940. According to one embodiment of the presentinvention, credential identifier 910 comprises a unique identifierassigned to a user. According to one embodiment of the presentinvention, credential identifier 910 comprises a randomized identifierassigned to the user.

[0107] Credential cryptogram 915 is used to authenticate credentialitems 925, 930, 935 and 940. Preferably, credential cryptogram 915 isalso used to authenticate credential authority peer group ID 920. Thisdata authentication may use a key and an algorithm as specified by thecredential authority or authorities. The keys and the dataauthentication algorithm may be specified as a credential parameter 925.

[0108] According to one embodiment of the present invention, the entirecredential cryptogram (915, 945) is used as the credential ID. Accordingto other embodiments of the present invention, a subset of thecryptogram is used as the credential ID.

[0109] Credential authority peer group ID 920 identifies the entity thatprovided data authentication for the credential 900. The entity thatprovided data authentication may comprise a single server.Alternatively, the entity that provided data authentication may comprisemultiple credential authority servers, one of which maintains credentialdata corresponding to the credential ID. Credential authority serverscomprising a particular credential authority peer group cooperate tolocate credential data corresponding to the credential ID.

[0110] Credential parameters 925 refer to named parameter data.Credential parameters may include, by way of example, dataauthentication mechanisms or user authentication mechanisms. Credentialparameters may also specify the identity of a user authentication servercapable of performing at least part of the user authentication requiredfor issuance of the requested credential. The credential parameters 925may also specify a credential data format and mechanisms used to seal orunseal credential data. The credential parameters 925 may also include aquality of service (QoS) identifier. The QoS identifier indicates theverification performed by issuer of the credential during userenrollment. The verification may include user authentication. Theverification may also include assessing the quality of any supportingcredentials. The verification may also include assessing thetruthfulness, accuracy and completeness of the credential data.

[0111] Credential data 930 comprise data associated with the credential.Sealed credential data 935 comprise encrypted credential data. Nestedcredentials 940 comprise one or more additional credentials. Note thatonly credential cryptogram 915 must be authenticated to perform securenesting.

[0112] The combination of the credential ID 910, the credentialcryptogram 915 and the credential authority peer group ID 920 may beused to represent the entire credential 900. The rest of the credential(reference numerals 925, 930, 935 and 940) may be stored separately. Forexample, the credential ID 910, credential cryptogram 915 and credentialauthority peer group ID 920 may be stored in a secure device such as asmart card, while the rest of the credential (reference numerals 925,930, 935 and 940) is stored on a Web server.

[0113]FIG. 9B is similar to FIG. 9A except that FIG. 9A includes aseparate credential ID 910, whereas the credential illustrated by FIG.9B uses the credential cryptogram 945 as an identifier.

[0114] Credential data elements 910-940 may be stored together.Alternatively, some credential elements 910-920 may be used to representa fall credential and other credential elements 925-940 may be storedseparately.

[0115] Turning now to FIG. 9B, a block diagram that illustrates acredential that uses a cryptogram as an identifier in accordance withone embodiment of the present invention is presented. FIG. 9B is similarto FIG. 9A except that credential cryptogram 945 in FIG. 9B is also usedas an identifier.

[0116] Turning now to FIG. 10, a flow diagram that illustrates a methodfor generating a credential in accordance with one embodiment of thepresent invention is presented. FIG. 10 provides more detail forreference numeral 800 of FIG. 8. At 1000, a credential authorityreceives a credential request including one or more supportingcredentials. The supporting credentials may include credentials createdpreviously by the credential authority. The supporting credentials mayalso include credentials created previously by another credentialauthority. At 1005, the credentials are processed. At 1010, adetermination is made regarding whether the credentials were processedsuccessfully. If the credentials were not processed successfully, afailure is registered at 1015 and a failure policy is applied at 1020.The failure policy specifies actions to performed when a failure isdetected. An exemplary failure policy performs a user notificationfunction when the error is detected.

[0117] Still referring to FIG. 10, if the credentials were processedsuccessfully, a new credential is created at 1025 and at 1030 thecredential is returned to the user that requested it. According to oneembodiment of the present invention, the entire credential is returnedto the user. According to another embodiment of the present invention,unique identifying information of the credential is returned and therest of the credential is stored separately. For example, an embodimentusing the credential format of FIG. 9A would return the credential ID910, the credential cryptogram 915 and the credential authority peergroup ID 920. An embodiment using the credential format of FIG. 9B wouldreturn the credential cryptogram 945 and the credential authority peergroup ID 950.

[0118] Turning now to FIG. 11, a flow diagram that illustrates a methodfor processing a credential in accordance with one embodiment of thepresent invention is presented. FIG. 11 provides more detail forreference numeral 1005 of FIG. 10. At 1100, cryptographic dataauthentication of the credential is performed. Using the credentialformat of FIG. 9A as an example, credential cryptogram 915 is used toauthenticate credential fields 925, 930, 935 and 940. Alternatively, aparticular data authentication mechanism may also authenticate thecredential peer group ID 920. Using the credential format of FIG. 9B asan example, credential cryptogram 945 is used to authenticate credentialfields 955, 960, 965 and 970. Again, a particular data authenticationmechanism may also authenticate the credential authority peer group ID950. At 1105, a determination is made regarding whether the credentialcryptogram authenticates the credential data. If the credentialcryptogram does not authenticate the credential data, the process endswith a failure indication at 1145.

[0119] Referring again to FIG. 11, at 1110 successful cryptographic dataauthentication is followed by the application of credential evaluationpolicies to (1) obtain the credential data if it is stored separately,(2) decrypt encrypted credential data and (3) determine credential datavalidity. At 1120 the credential data is assessed to ensure that thecredential data is proper in terms of the type of credential datapresented, the content of the credential data and the required qualityof service (QoS). At 1130 user authentication is performed to ensure thecredentials are associated with the user who is actually making thecredential request. If the result of reference numerals 1100, 1110, 1120or 1130 is a failure, the process ends with a failure indication at1145. Otherwise, the process ends successfully at 1140.

[0120] Turning now to FIG. 12, a flow diagram that illustrates a methodfor applying credential evaluation policies in accordance with oneembodiment of the present invention is presented. FIG. 12 provides moredetail for reference numeral 1110 of FIG. 11. As discussed above, theunique identifying information of a credential may be stored separatelyfrom the rest of the credential data. Thus, at 1200 a determination ismade regarding whether credential data is included in the credential. Ifcredential data is not included in the credential, the credential datais obtained at 1205. If credential data is included in the credential, adetermination is made at 1210 regarding whether all embedded credentialsthat are needed are included in the credential. If not all suchcredentials are included, the needed credentials are obtained at 1215.If all needed credentials are included, a determination is made at 1220regarding whether any data in the credential must be unsealed. Thecredential data to be unsealed may include nested credential data. Ifdata must be unsealed, it is unsealed at 1225. If no data needs to beunsealed, at 1230 a determination is made regarding whether thecredential data is valid. If the data is invalid, the process ends witha failure indication at 1240. If the data is valid, the process endssuccessfully at 1240.

[0121] Turning now to FIG. 13, a flow diagram that illustrates a methodfor assessing credential data in accordance with one embodiment of thepresent invention is presented. FIG. 13 provides more detail forreference numeral 1120 of FIG. 11. At 1300, a determination is maderegarding whether the type of credential data presented is sufficientfor the request made. In other words, the credential is evaluated forcompleteness. For example, if the credential authority requires adriver's license for a particular credential request, a determination ismade regarding whether the credential data includes a driver's license.If the credential data does not include a driver's license, thecredential data is insufficient for the request. If the credential datais insufficient, the request is rejected. Alternatively, the user couldbe prompted for the required credential data.

[0122] Still referring to FIG. 13, at 1305 a determination is maderegarding whether the credential data presented matches the request. Thecontent of the credential data is evaluated. For example, suppose thecredential-granting policy for a particular credential requires a validdriver's license. In this case, whether the credential request includesa driver's license is determined at 1300, whereas whether the driver'slicense is expired is determined at 1305. If this determination endsunsuccessfully, a failure indication is returned at 1325. The processillustrated by FIG. 13 is used to assess credentials both by anauthority during the enrollment process, and by a service provider inthe process of providing a service. An authority creates a credentialand therefore must assign values to credential data such as the QoSindicator. A service provider provides a service and does not need tocreate a credential (unless the service provider is actually anauthority that provides credentials as a service). Thus, at 1330 adetermination is made regarding whether a credential needs to becreated. If a credential needs to be created, at 1315 the quality ofservice (QoS) of the credential being created is determined.

[0123] As part of validating credential data, an authority or serviceprovider may require a certain level of user authentication. Userauthentication determines whether the credentials are associated with orbelong to the user that is actually making the request, as opposed tosomeone else masquerading as the real user. User authentication mayinclude, by way of example, asking for additional biometrics such as afingerprint or retinal scan or the like. User authentication may alsoinclude a password challenge delivered to a cell phone known to belongto the user.

[0124] The QoS is a way of transferring information about how acredential was created to other entities that use or access thecredential. The QoS is a reference to a policy statement established byan authority or group of authorities. For example, the QoS parameter ofthe credential may indicate the authority checked the user's driverslicense or birth certificate. A different QoS might indicate theauthority checked the user's drivers license, birth certificate andsocial security card.

[0125] A credential may include a QoS indicator that indicates the levelof user authentication performed by the entity that authenticated thecredential. A service provider may determine that the QoS indicated in acredential is insufficient to grant a service request. If so, theservice provider may require additional user authentication. TheCredential may also contain information regarding a user authenticationserver that is capable of performing additional user authentication.

[0126] According to another embodiment of the present invention, a logoncredential includes a nested credential that asserts a particularprocess for user authentication. In other words, a logon credentialincludes a nested credential that includes a QoS for userauthentication. The logon credential has its own QoS parameter embeddedas part of its credential parameter. The logon credential also has apredetermined lifetime. For example, the QoS parameter of the logoncredential could require a particular form of additional userauthentication (such as a fingerprint or other biometrics) atpredetermined intervals or events.

[0127] According to one embodiment of the present invention, a firstcredential is used to make a new credential having a more limited scope.For example, a first credential that grants access to view a web page orinformation unit may be used to create a second credential that providesaccess to a second Web page directly referenced by the first Web pagefor only 10 minutes. The same first credential might be used to create athird credential that provides access to any other Web pages referenceddirectly from the current Web page. More examples of using one or morecredentials to create another credential are presented below withreference to FIG. 39.

[0128] Turning now to FIG. 14, a flow diagram that illustrates a methodfor performing user authentication in accordance with one embodiment ofthe present invention is presented. FIG. 14 provides more detail forreference numeral 1130 of FIG. 11. At 1400, a determination is maderegarding whether user authentication is required. This determination isbased upon the user-provided user authentication credential and therequired QoS. If the user-provided user authentication credentialprovides a QoS that is less than the required QoS, additional userauthentication is required. If user authentication is required, at 1405a determination is made regarding whether user-provided or nestedcredentials are sufficient to satisfy the required QoS if creating acredential, or as required by a service provider. If these credentialsare insufficient, user authentication is performed at 1410.

[0129] Turning now to FIG. 15, a flow diagram that illustrates a methodfor using a credential to obtain services in accordance with oneembodiment of the present invention is presented. FIG. 15 provides moredetail for reference numeral 810 of FIG. 8, including actions performedby a user and a server. At 1500, a user visits a Web site. At 1505, aservice request and one or more credentials associated with the user arepresented to the service provider server. At 1540, the server receivesthe service request and credentials. At 1550, the service providerprocesses the credentials as described above with respect to FIG. 11. At1555, the server determines whether the credentials were processedsuccessfully. If the credentials were processed unsuccessfully, therequested service is denied at 1560 and a service denial 1565 is sent tothe user that requested the service. If the credentials were processedsuccessfully, the service is provided at 1570. At 1510, the userdetermines whether the service request was successful. If the servicerequest was unsuccessful, a failure indication is made at 1520 and theprocess ends at 1525. If the service request was successful, the serviceis used at 1530.

[0130] FIGS. 16-33 illustrate embodiments of the present invention thatuse user data stored in secure user data storage to enhance privacy onthe World Wide Web. FIGS. 17-23 illustrate embodiments of the presentinvention that use user data stored in secure user data storage. FIGS.24-30A illustrate embodiments of the present invention that employ acredential format for user data. The credential format is as wasillustrated above with respect to FIGS. 9A and 9B. FIGS. 30B-33illustrate embodiments of the present invention that use a smart cardfor secure user data storage.

[0131] Turning now to FIG. 16, a block diagram that illustratesassigning multiple identities to an individual in accordance with oneembodiment of the present invention is presented. As shown in FIG. 16,an individual 1600 may have multiple identities for different purposes.An individual 1600 may be a customer of a payment authority such as acredit card (1602, 1618), a golfer 1604, a member of the military 1606and a medical patient 1608. An individual may also be a student 1610, aninvestor 1612, an employee 1614, a university alumnus 1616 and anautomobile driver 1620. Each of identities 1602-1620 is tied to relevantdata. For example, relevant data for golfer identity 1604 may includethe golfer's handicap 1624. Relevant data for medical patient identity1608 may include a patient's medical history 1628. However, the golferidentity 1604 does not need to know any medical history information 1628and the medical patient identity 1608 does not need to know about golfhandicaps 1624.

[0132] Still referring to FIG. 16, some or all of the relevant data foran identity may be the same as relevant data for another identity. Forexample, some relevant data (such as degree program) for studentidentity 1610 may be the same as relevant data for alumnus identity1616.

[0133] Turning now to FIG. 17, a block diagram that illustratesassigning multiple sets of user data for identities in accordance withone embodiment of the present invention is presented. As shown in FIG.17, the user data 1704-1720 is stored in secure user data storage 1702.Secure user data storage 1702 is controlled by a user (user-controlled).The user data 1704-1720 may include encrypted data and/or authenticateddata. Secure user data storage 1702 may comprise a portable device suchas a cell phone, PDA or smart card or the like. Secure user data storage1702 may also comprise a file on a Web server or other computer.

[0134] According to one embodiment of the present invention, a portionof the user data is bit-mapped. The user data may be bit-mapped basedupon, by way of example, based on membership in a group or category. Forexample, a portion of a user's data may be bit-mapped according tocategories of books that the user is interested in.

[0135] Turning now to FIG. 18, a block diagram that illustratesconducting transactions between multiple parties on an open networkwhile maintaining privacy in accordance with one embodiment of thepresent invention is presented. FIG. 18 illustrates buying a productfrom a vendor Web site. Secure user data storage 1802 stores multiplesets of user data for identities as illustrated previously with respectto reference numeral 1702 of FIG. 17. Secure user data storage 708 mayreside on a desktop computer, a smart card, a PDA or the like. At 1826,a user enrolls with payment agent 1 (1810) at the payment agent's Website. User data specific to the enrollment of that user is stored insecure user data storage 1802. Payment agent 1 (1810) determines whetheruser authentication is required. If user authentication is required,payment agent 1 (1810) also determines the required level of userauthentication. In addition, payment agent 1 (1810) determines whetheruser data specific to the enrollment of the user must be encrypted.

[0136] According to embodiments of the present invention, userenrollment data includes user authentication information used forsubsequent visits to a service provider Web site. In other words, theservice provider-specific user or a reference to the user data data ispresented to the service provider Web site whenever the user data set isused to visit the same service provider Web site. The userauthentication requirements of a particular service provider Web sitewill determine whether additional user authentication is required. Forexample, the stored user authentication data may suffice for a repeatvisit to an Internet-based email site, but signing into a military Website may require additional user authentication measures such asbiometrics each time the site is visited, regardless of the stored userauthentication data.

[0137] Still referring to FIG. 18, at 1828, the same user data set isused to enroll with shipping agent 1818. Thus, the shipping agent Website 1818 performs any required data authentication and/or encryption ofthe user data and returns the user data to secure user data storage1802. At this point, secure user data storage 1802 includes a user dataset that has been used to enroll with two Web sites (1810, 1818). At1830, the user data set is used to shop for items at the Web site ofVendor A (1806). Once items are selected for purchase, Vendor A 1806sends the user data to payment agent 1 (1810) for payment authorization.Payment agent ( 18810) decrypts user data if required user data isencrypted. Payment agent 1 (1810) uses the user data in conjunction withvendor-provided transaction details to determine whether the purchase isauthorized. At 1832, payment agent 1 (1810) sends an authorizationindication to Vendor A 1806. Next, Vendor A 1806 creates a fulfillmentrecord that includes order information and the shipping information fromthe secure user data storage 1802. At 1838, Vendor A 1806 sends thefulfillment record to Fulfillment Company 1814 and the FulfillmentCompany 1814 fulfills the order using shipping information from thefulfillment record originating from the user data. At 1840, thefulfillment company 1814 transfers the purchased goods to the shippingagent 1818. At 1842, the shipping agent delivers the goods to theaddress in the shipping information from secure data storage 1 (1802).

[0138] Many other devices or subsystems (not shown) may be connected ina similar manner. Also, it is not necessary for all of the devices shownin FIG. 7 to be present to practice the present invention, as discussedbelow. Furthermore, the devices and subsystems may be interconnected indifferent ways from that shown in FIG. 7. Code to implement the presentinvention may be operably disposed in a system memory or stored onstorage media such as a fixed disk, floppy disk or CD-ROM.

[0139] According to one embodiment of the present invention, a Web sitemaintains a profile for the user. One exemplary use of a profile is totrack the activity of a user at a particular Web site. The profilemaintains information regarding the nature of the user activities withVendor A 1806. For example, the profile may maintain informationregarding the frequency of visits, the items previously purchased, theitems examined but not purchased, the preferred shipping method and thepreferred payment method, allowing Vendor A 1806 to provide intelligentservices tailored to the buying pattern of a particular user data set.

[0140] The same process described above with regard to user data sets insecure user data storage 1 (1802) applies to user data sets in secureuser data storage 2 (1804) as well.

[0141] Turning now to FIG. 19, a flow diagram that illustrates a methodfor conducting transactions between multiple parties on an open networkwhile maintaining privacy in accordance with one embodiment of thepresent invention is presented. At 1900, a user receives auser-controlled storage device, or a key to control access to such adevice on the Web. At 1905, a determination is made regarding whether itis time to enroll with a service provider. When it is time to enrollwith a service provider, at 1910 user data resulting from the enrollmentprocess is stored on a user-controlled secure storage device. Some userdata may be encrypted. Additionally, some user data may becryptographically authenticated. At 1915, a determination is made by theuser regarding whether it is time to use the user data stored on theuser-controlled secure storage device. When it is time to use the userdata, at 1920 the user data stored on the user-controlled secure storagedevice is used to obtain one or more services. At 1925, a determinationis made regarding whether the user data is still valid. If the user datais still valid, execution continues at 1915. If the user data is nolonger valid, it is discarded at 1930.

[0142] According to one embodiment of the present invention, user datarequired to obtain a new service is obtained by dynamically combiningthe request for new service with at least one user data set obtainedfrom a previous enrollment. For example, a user that shops at a firstbook vendor Web site may exhibit one or more preferences for booksbelonging to certain categories, based both on the books purchased atthe Web site and on the books examined but not purchased. The first bookvendor may save this information in a profile. The user may want to useall or part of this information when the user shops at a second bookvendor Web site. Accordingly, a service request made by the user forservice at the second book vendor Web site is automatically combinedwith the profile information used when shopping at the first book vendorWeb site, thus creating a new profile for use by the user when shoppingat the second book vendor Web site.

[0143] Turning now to FIG. 20, a flow diagram that illustrates a methodfor using user data stored on a user-controlled device to obtainservices in accordance with one embodiment of the present invention ispresented. FIG. 20 provides more detail for reference numeral 1920 ofFIG. 19. At 2000, a user visits a Web site. At 2005, a service requestand associated user data are presented to the service provider server.At 2030, the server receives the service request and associated userdata. At 2040, the service provider processes the user data to determinewhether the user data provided is sufficient to grant the request. At2045, the server determines whether the user data was processedsuccessfully. If the user data was processed unsuccessfully, therequested service is denied at 2050 and a service denial 2055 is sent tothe user that requested the service. If the user data was processedsuccessfully, the service is provided at 2060. At 2010, the userdetermines whether the service request was successful. If the servicerequest was unsuccessful, a failure indication is made at 2015 and theprocess ends at 2075. If the service request was successful, the serviceis used at 2025.

[0144]FIGS. 21 and 22 provide more detail for reference numeral 2060 ofFIG. 20. FIG. 21 illustrates providing a service by customizing a Website based on user data stored on a user-controlled device, while FIG.22 illustrates providing a service by using the user data stored on auser-controlled device to purchase a product and have the productdelivered to the user. The examples of providing a service are notintended to be limiting in any way. Those of ordinary skill in the artwill recognize that many other forms of service may be provided.

[0145] Turning now to FIG. 21, a flow diagram that illustrates a methodfor providing a service in accordance with one embodiment of the presentinvention is presented. FIG. 21 provides more detail for referencenumeral 2060 of FIG. 20. At 2100, user data is received. At 2105, one ormore Web pages at a Web site is customized based on the user data storedon a user-controlled device.

[0146] Turning now to FIG. 22, a flow diagram that illustrates a methodfor providing a service in accordance with user data in accordance withone embodiment of the present invention is presented. FIG. 22 providesmore detail for reference numeral 2060 of FIG. 20. At 2200 a vendorperforms payment authorization using payment data from a user-controlledsecure device. At 2205 the vendor creates a fulfillment record thatincludes order information and the shipping information from theuser-controlled secure device. At 2210, the vendor sends a fulfillmentrecord to a fulfillment company. At 2215, the fulfillment companyfulfills the order using shipping information from the fulfillmentrecord originating from the user data. At 2220, the fulfillment companytransfers the purchased goods to the shipping agent. At 2225, theshipping agent delivers the goods to the address in the shippinginformation from the user-controlled secure device.

[0147] Turning now to FIG. 23, a flow diagram that illustrates a methodfor performing payment authorization using payment data from a securedevice in accordance with one embodiment of the present invention ispresented. FIG. 23 provides more detail for reference numeral 2200 ofFIG. 22. At 2300, the vendor sends a payment request to apayment-clearing agent using the payment data originating from thesecure device, including transaction details such as the amount to becharged in the request. At 2305, the payment-clearing agent receives thepayment request and the amount to be charged. At 2310, thepayment-clearing agent sends a response. For example, the paymentclearing agent may send a transaction ID and the amount charged.Depending upon the contents of the response, all or part of the responsemay comprise a cryptographically encrypted message.

[0148] FIGS. 24-30A illustrate embodiments of the present invention thatemploy a credential format for user data. The credential format is aswas illustrated above with respect to FIGS. 9A and 9B. Use of thecredential format is presented for illustrative purposes only. Those ofordinary skill in the art will recognize that other formats may be used.

[0149] Turning now to FIG. 24, a block diagram that illustratesassigning multiple credentials for identities in accordance with oneembodiment of the present invention is presented. FIG. 24 is similar toFIG. 17, except that service credentials 2404-2420 are stored in thesecure device 2402. In other words, the service credentials 2404-2420 ofFIG. 24 are based upon and contain, directly or indirectly, the userdata 1704-1720 of FIG. 17.

[0150] Turning now to FIG. 25, a block diagram that illustratesconducting transactions between multiple parties using servicecredentials on an open network while maintaining privacy in accordancewith one embodiment of the present invention is presented. FIG. 25illustrates buying a product from a vendor Web site. Secure servicecredential storage 2502 stores multiple sets of service credential foridentities as illustrated previously with respect to reference numeral2402 of FIG. 24. Secure service credential storage 2502 may reside on adesktop computer, a smart card, a PDA or the like. At 2526, a userenrolls with payment agent 1 (2510) at the payment agent's Web site. Aservice credential specific to the enrollment of that user is stored insecure service credential storage 2502. Payment agent 1 (2510)determines whether user authentication is required. If userauthentication is required, payment agent 1 (2510) also determines therequired level of user authentication. In addition, payment agent 1(2510) determines whether user data included in the service credentialspecific to the enrollment of the user must be encrypted.

[0151] According to embodiments of the present invention, user dataincludes user authentication information used for subsequent visits to aservice provider Web site. In other words, the authority-specificauthentication data or a reference to the data is presented to theservice provider Web site whenever the service credential is used tovisit the same service provider Web site. The user authenticationrequirements of a particular service provider Web site will determinewhether additional user authentication is required. For example, thestored user authentication data may suffice for a repeat visit to anInternet-based email site, but signing into a military Web site mayrequire additional user authentication measures such as biometrics eachtime the site is visited, regardless of the stored user authenticationdata.

[0152] Still referring to FIG. 25, at 2528, the user 2500 enrolls withshipping agent 2518, providing specific data such as a shipping address.Data provided at 2528 when enrolling with shipping agent 2518 may differin whole or in part from data provided when enrolling with payment agent2510 at 2526. Thus, the shipping agent Web site 2518 performs anyrequired data authentication and/or encryption of the service credentialand returns the service credential to secure service credential storage2502. At this point, secure service credential storage 2502 includes aservice credential set that has been created by enrolling with two Websites (2510, 2518) functioning as authorities. At 2530, the servicecredential set is used to obtain service such as shopping at the Website of Vendor A (2506). Once items are selected for purchase, Vendor A2506 sends the service credential obtained from the secure servicecredential storage to payment agent 1 (2510) for payment authorization.Payment agent 1 (2510) decrypts any data contained in a servicecredential if any required data is encrypted. Payment agent (2510) usesdata contained in the service credential in conjunction withvendor-provided transaction details to determine whether the purchase isauthorized. At 2532, payment agent 1 (2510) sends an authorizationindication to Vendor A 2506. Next, Vendor A 2506 creates a fulfillmentmessage that includes order information and the shipping informationobtained from the secure service credential storage 2502. According toone embodiment of the present invention, the fulfillment messagecomprises a fulfillment credential. At 2538, Vendor A 2506 sends thefulfillment message to Fulfillment Company 2514 and the FulfillmentCompany 2514 fulfills the order using shipping information from thefulfillment message, At 2540, the Fulfillment Company 2514 transfers thepurchased goods to the shipping agent 2518. At 2542, the shipping agentdelivers the goods to the address in the shipping informationoriginating from secure data storage 1 (2502).

[0153] Turning now to FIG. 26, a flow diagram that illustrates a methodfor conducting transactions between multiple parties using servicecredentials on an open network while maintaining privacy in accordancewith one embodiment of the present invention is presented. At 2600, aservice credential is generated. At 2605, a determination is maderegarding whether it is time to use the credential. When it is time touse the service credential, at 2610 the service credential is used toobtain services. At 2615, a determination is made regarding whether theservice credential is still valid. If the service credential is stillvalid, at 2620 a determination is made regarding whether the servicecredential must be updated. If the service credential must be updated,it is updated at 2625. Execution continues at 2605 when the servicecredential is still valid. If the service credential is no longer valid,it is discarded at 2630.

[0154] Turning now to FIG. 27, a block diagram that illustrates usingnested credentials in accordance with one embodiment of the presentinvention is presented. FIG. 27 illustrates using the credential formatof FIG. 9B for the example discussed with reference to FIG. 25. In thisexample, a user on Jan. 1, 2002 initiates a Web experience. Logincredential 2700 allows the user access to the Web. Logon credential 2700includes two credential parameters 2808. The “Type” parameter indicatesthe credential is a “Logon” credential, and credential data is a userprofile. The “QoS” parameter indicates a (username, password)combination has been used to authenticate a user. The “expiry” parameteralso indicates the credential expires on Jan. 1, 2002. The credentialdata 2710 includes a bit-mapped customer profile and there is no sealedcredential data 2712. Logon credential 2700 also includes nestedcredentials 2714. Reference numeral 2702 illustrates an expanded view ofnested credentials 2714.

[0155] The nested credentials (2714, 2702) include a payment credential2716 and a shipping agent credential 2718. The payment credentialparameters 2724 indicate the credential is a credit card paymentcredential. The credential data 2726 includes the purchase class forwhich the holder of the credential is approved. Examples of a purchaseclass include, by way of example, a hotel payment or a book payment fora specific maximum value. The sealed credential data 2728 includes thecard holder details such as the account number and the actual creditlimit.

[0156] The shipping agent credential parameters 2736 indicate thecredential is a “shipping” credential. The credential data 2738 includesthe customer's nearest shipping agent location and the type of service.The sealed credential data 2740 includes the shipping agent accountnumber and the shipping address.

[0157] Turning now to FIG. 28A, a flow diagram that illustrates a methodfor conducting transactions between multiple parties using servicecredentials on an open network while maintaining privacy in accordancewith one embodiment of the present invention is presented. At 2800, asecure service credential storage device is received. At 2805, adetermination is made regarding whether it is time to enroll with anauthority. When it is time to enroll, at 2810 a service credential isgenerated based on user information provided in the enrollment request.At 2815, the credential cryptogram and credential authority peer groupID are stored. They may be stored in a user-controlled personal device.Examples of user-controlled personal devices include, by way of example,a smart card, a cell phone, a personal digital assistant (PDA) or thelike. Alternatively, they may be stored in a Web locker and the digitalkey to the locker may be stored in a secure device. At 2820, adetermination is made regarding whether it is time to use the servicecredential. When it is time to use the service credential, at 2825 theservice credential is used to obtain services. At 2830, a determinationis made regarding whether the service credential is still valid. If theservice credential is still valid, at 2835 a determination is maderegarding whether the service credential must be updated. If the servicecredential must be updated, it is updated at 2840. Execution continuesat 2820 when the credential is still valid. If the credential is nolonger valid, it is discarded at 2845.

[0158] Turning now to FIG. 28B, a flow diagram that illustrates a methodfor using a service credential stored on a user-controlled device toobtain services in accordance with one embodiment of the presentinvention is presented. FIG. 28B provides more detail for referencenumeral 2825 of FIG. 28A. FIG. 28B is similar to FIG. 20 except thatFIG. 28B illustrates using a service credential whereas FIG. 20illustrates using user data.

[0159] Turning now to FIG. 29, a flow diagram that illustrates a methodfor providing a service in accordance with one embodiment of the presentinvention is presented. FIG. 29 provides more detail for referencenumeral 2850 of FIG. 28B. At 2900, a vendor performs paymentauthorization using a nested payment credential extracted from acustomer service credential specific to what is being bought. At 2905,the vendor creates a fulfillment message that includes order informationand the shipping credential extracted from the customer servicecredential. According to one embodiment of the present invention, thefulfillment message comprises a fulfillment credential. At 2910 thevendor sends the fulfillment message to the fulfillment company. At2915, the fulfillment company fulfills the order using the nestedshipping credential extracted from the fulfillment message. At 2920, thefulfillment company transfers the purchased goods to the shipping agent.At 2925, the shipping agent delivers the goods to the address encryptedin the sealed part of the credential.

[0160] The use of the credential format in the above example is notintended to be limiting in any way. Those of ordinary skill in the artwill recognize that other data formats may be used.

[0161] According to one embodiment of the present invention, rather thanusing a fulfillment company to fulfill the order, after the fulfillmentmessage is created (reference numeral 2905 of FIG. 29), the fulfillmentmessage is stored on a secure service credential storage device.According to one embodiment of the present invention, the fulfillmentmessage is stored on a portable device such as a PDA, cell phone orsmart card. According to another embodiment of the present invention, adigital key to a Web locker that contains the fulfillment credential isstored on the device. The user then brings the secure service credentialstorage device to the vendor's store and presents the service credentialto the vendor in person. The vendor processes the credential andperforms any required user authentication. Once the user is properlyauthenticated, the vendor presents the purchased item to the customer.

[0162] Turning now to FIG. 30A, a flow diagram that illustrates a methodfor performing a payment authorization using nested payment credentialsextracted from a service credential in accordance with one embodiment ofthe present invention is presented. FIG. 30A provides more detail forreference numeral 2900 of FIG. 29. At 3000, the vendor sends a paymentrequest to the payment-clearing agent using the nested paymentcredential from the service credential, including in the requesttransaction details such as the amount to be charged. At 3005, thepayment-clearing agent decrypts the sealed part of the nestedcredential. At 3010, the payment-clearing agent sends a response. Forexample, the clearing agent may send a response that includes atransaction identifier and the amount charged. . Depending upon thecontents of the response, all or part of the response may comprise acryptographically encrypted message.

[0163] FIGS. 30B-33 illustrate embodiments of the present invention thatuse a smart card for secure user data storage.

[0164] Resource-constrained devices are generally considered to be thosethat are relatively restricted in memory and/or computing power orspeed, as compared to typical desktop computers and the like. Althoughthe particular implementation discussed below is described in referenceto a smart card, the invention can be used with otherresource-constrained devices including, but not limited to, cellulartelephones, boundary scan devices, field programmable devices, personaldigital assistants (PDAs) and pagers, as well as other miniature orsmall footprint devices. The invention can also be used on non-resourceconstrained devices.

[0165] For the purpose of this disclosure, the term “processor” may beused to refer to a physical computer or a virtual machine.

[0166] Turning now to FIG. 30B a block diagram that illustratesassigning multiple sets of user data for identities in accordance withone embodiment of the present invention is presented. FIG. 31A issimilar to FIG. 17, except a smart card 3050 is used for secure datastorage (reference numeral 1702 of FIG. 17).

[0167] Turning now to FIG. 31, a block diagram that conductingtransactions between multiple parties using a smart card on an opennetwork while maintaining privacy in accordance with one embodiment ofthe present invention is presented. FIG. 31 is similar to FIG. 18,except a smart card (3102, 3104) is used for secure user data storage(reference numerals 1802 and 1804 of FIG. 18).

[0168] Turning now to FIG. 32, a block diagram that illustratesdevelopment of an applet as may be used to provide a secure user accesscontrol function for a resource-constrained device such as a smart cardis presented. Development of an applet for a resource-constrained devicesuch as a smart card 3240 begins in a manner similar to development of aJava™ program. In other words, a developer writes one or more Java™classes and compiles the source code with a Java™ compiler to produceone or more class files 3210. The applet can be run, tested anddebugged, for example, on a workstation using simulation tools toemulate the environment on the card 3240. When the applet is ready to bedownloaded to the card 3240, the class files 3210 are converted to aconverted applet (CAP) file 3216 by a converter 3214. The converter 3214can be a Java™ application being executed by a desktop computer. Theconverter 3214 can accept as its input one or more export files 3212 inaddition to the class files 3210 to be converted. An export file 3212contains naming or linking information for the contents of otherpackages that are imported by the classes being converted.

[0169] In general, the CAP file 3216 includes all the classes andinterfaces defined in a single Java™ package and is represented by astream of 8-bit bytes. All 16-bit and 32-bit quantities are constructedby reading in two or four consecutive 8-bit bytes, respectively. Amongother things, the CAP file 3216 includes a constant pool component (or“constant pool”) 3218 which is packaged separately from a methodscomponent 3220. The constant pool 3218 can include various types ofconstants including method and field references which are resolvedeither when the program is linked or downloaded to the smart card 3240or at the time of execution by the smart card. The methods component3220 specifies the application instructions to be downloaded to thesmart card 3240 and subsequently executed by the smart card.

[0170] After conversion, the CAP file 3216 can be stored on acomputer-readable medium 3217 such as a hard drive, a floppy disk, anoptical storage medium, a flash device or some other suitable medium. Orthe computer-readable medium can be in the form of a carrier wave, e.g.,a network data transmission, or a radio frequency (RF) data link.

[0171] The CAP file 3216 then can be copied or transferred to a terminal3222 such as a desktop computer with a peripheral card reader 3224. Thecard reader 3224 allows information to be written to and retrieved fromthe smart card 3240. The card reader 3224 includes a card port (notshown) into which the smart card 3240 can be inserted. Once inserted,contacts from a connector press against the surface connection area onthe smart card 3240 to provide power and to permit communications withthe smart card, although, in other implementations, contactlesscommunications can be used. The terminal 3222 also includes aninstallation tool 3226 that loads the CAP file 3216 for transmission tothe card 3240.

[0172] The smart card 3240 has an input/output (I/O) port 3242 that caninclude a set of contacts through which programs, data and othercommunications are provided. The card 3240 also includes an installationtool 3246 for receiving the contents of the CAP file 3216 and preparingthe applet for execution on the card 3240. The installation tool 3246can be implemented, for example, as a Java™ program and can be executedon the card 3240. The card 3240 also has memory, including volatilememory such as RAM 3250. The card 3240 also has ROM 3252 andnon-volatile memory, such as EEPROM 3254. The applet prepared by thecontroller 3244 can be stored in the EEPROM 3254.

[0173] In one particular implementation, the applet is executed by avirtual machine 3249 running on a microprocessor 3248. The virtualmachine 3249, which can be referred to as the Java Card™ virtualmachine, need not load or manipulate the CAP file 3216. Rather, the JavaCard™ virtual machine 3249 executes the applet code previously stored aspart of the CAP file 3216. The division of functionality between theJava Card™ virtual machine 3249 and the installation tool 3246 allowsboth the virtual machine and the installation tool to be kept relativelysmall.

[0174] In general, implementations and applets written for aresource-constrained platform such as the smart card 3240 follow thestandard rules for Java™ platform packages. The Java™ virtual machineand the Java™ programming language are described in T, Lindholm et al.,The Java™ Virtual Machine Specification (1997), and K. Arnold et al.,The Java™ Programming Language Second Edition, (1998). Applicationprogramming interface (API) classes for the smart card platform can bewritten as Java™ source files which include package designations, wherea package includes a number of compilation units and has a unique name.Package mechanisms are used to identify and control access to classes,fields and methods. The Java Card™ API allows applications written forone Java Card™-enabled platform to run on any other Java Card™-enabledplatform. Additionally, the Java Card™ API is compatible with formalinternational standards such as ISO 7816, and industry-specificstandards such as Europay/MasterCard/Visa (EMV).

[0175] Although a virtual machine 3249 running on a microprocessor 3248has been described as one implementation for executing the bytecodes onthe smart card 3240, in alternative implementations, anapplication-specific integrated circuit (ASIC) or a combination of ahardware and firmware can be used instead.

[0176] Referring to FIG. 32, controller 3244 uses an installation tool3246 for receiving the contents of the CAP file 3216 and preparing theapplet to be executed by a processor 3248. The installation tool 3246can be implemented, for example, as a Java™ program that has beensuitably converted to execute on the smart card 3240. In the descriptionbelow, it is assumed that the controller 3244 comprises a virtualmachine program 3249 running on a microprocessor 3248. The virtualmachine 3249 need not load or manipulate the CAP file 3216. Rather, thevirtual machine 3249 executes the applet code in the Cap file 3216. Thedivision of functionality between the virtual machine 3249 and theinstallation tool 3246 allows both the virtual machine and theinstallation tool to be kept relatively small. In alternativeimplementations, the controller 3244 can be hardwired, for example, asan application-specific integrated circuit (ASIC) or it can beimplemented as a combination of a hardware and firmware.

[0177] As shown in FIG. 33A, a computer 3322 is equipped with a cardreader 3324 for receiving the card 3240 of FIG. 32. The computer 3322may be connected to a data communications network 3345 that communicateswith a plurality of other computing devices, such as a server 3347. Itis possible to load data and software onto a smart card over the datacommunications network 3345 using card equipped devices. Downloads ofthis nature can include applets or other programs to be loaded onto asmart card as well as profile data, digital cash and other informationused in accordance with a variety of electronic commerce and otherapplications. The instructions and data used to control processingelements of the card reader and of the smart card may be stored involatile or non-volatile memory or may be received directly over acommunications link e.g., as a carrier wave containing the instructionsand/or data. Further, for example, the network 3345 can be a LAN or aWAN such as the Internet or other network.

[0178] According to embodiments of the present invention, multiple userdata formats may be used to store user data in the same secure user datastorage device. As shown in FIG. 33B, secure user data storage deviceTBD uses five user data formats: service credential (3340, 3344, 3356,3358), cookie (3342, 3350), data format A (3346), text file (3348, 3354)and data format B (3352). Those of ordinary skill in the art willrecognize that other formats are possible.

[0179]FIG. 33B is a block diagram that illustrates assigning varioustypes of user data for identities in accordance with one embodiment ofthe present invention.

[0180] Privacy-Protecting Logon Mechanisms

[0181] FIGS. 34-41 illustrate embodiments of the present invention thatuse a randomized user ID to protect a users identity on the World WideWeb.

[0182] For the purposes of this disclosure, the term “Randomized ID”refers to a pseudo-random identifier.

[0183] Turning now to FIG. 34, a block diagram that illustrates anidentifier in accordance with one embodiment of the present invention ispresented. Identifier 3400 includes an identification server ID 3405 anda randomized ID 3410. The identification server ID 3405 identifies acollection of one or more federated identity servers, including oneidentity server containing additional information associated with therandomized ID 3410. According to embodiments of the present invention,the identification randomized ID 3410 is computed over data that isassociated with the ID and that is stored in one of the federatedidentification servers. According to one embodiment of the presentinvention, the computation comprises using a cryptographic algorithm, inwhich case the ID 3410 comprises a cryptogram of the stored data asdescribed previously with respect to reference numeral 915 of FIG. 9Aand reference numeral 945 of FIG. 9B.

[0184] Turning now to FIG. 35, a block diagram that illustrates usingfederated identification servers and federated user authenticationservers using a randomized user identifier to gain access to a servicewhile maintaining privacy in accordance with one embodiment of thepresent invention is presented. FIG. 35 illustrates two mechanisms bywhich a user 3530 uses a personal device (3540, 3545, 3550) connected toa client host 3500 to gain access to one or more service providerservers 3515. Both mechanisms use the randomized ID of FIG. 34 toidentify a user, thus protecting user privacy. The first mechanismemploys a portal 3505 in communication with the client host 3500. Theportal performs identification and user authentication functions toenable connecting to a service provider 3515 via a personal device suchas a smart card 3540, PDA 3545 or cell phone 3550. The second mechanismallows access to services either directly from a personal device (3540,3545, 3550) or from a personal device (3540, 3545, 3550) via a clienthost 3500.

[0185] Client host 3500 comprises a terminal or kiosk capable ofreceiving user input and presenting user information. Client host 3500provides a user interface to the Web. Client host 3500 may be configuredwith a card reader to accept a smart card.

[0186] Service portal 3505 includes a user interface such as a Web pagetailored for starting the Web experience. The service portal 3505 is theplace where a user obtains a logon credential. The logon credential mayinclude a timestamp and an indication of the QoS of the userauthentication performed. Service providers may require additional userauthentication.

[0187] Service provider servers 3515 represent all Web serversaccessible on the Web, which are referenced through the service portal3505. Service provider servers 3505 comprise all the services accessibleon the Web that do not have their own portal but require that the userbe logged on. For the purposes of this disclosure, being “logged on”refers to the requirement for a particular server to processuser-specific information such as a user profile in conjunction withrendering a service. For example, service provider servers 3515 mayinclude credential authorities, shipping agents, payment agents, orderfulfillment companies and the like. Therefore, service provider servers3515 may be accessed by the user via the service portal 3505. One ormore of the service provider servers 3515 may also be accessed directlyusing a credential that references a service provider server, eitherdirectly or via a nested credential.

[0188] Federated identity servers 3520 assert the truthfulness, accuracyand completeness of data to be stored according to the qualitystatements associated with the data. A QoS may be a reference to apolicy statement that indicates the level of verification performed.

[0189] Federated user authentication servers 3525 perform userauthentication services in a peer group fashion, such as in the Gnutellathe peer-to-peer search protocol and JXTA™.

[0190] The PDA 3545 and cell phone 3550 may communicate with client host3500 using protocols including Bluetooth™, IEEE 802.15 and Infrared DataAssociation (IrDA) Data standards including Fast Infrared (FIR) andSerial Infrared. Those of ordinary skill in the art will recognize thatother protocols may be used as well.

[0191] The PDA 3545 and cell phone 3550 devices may be equipped with acard reader to accept an external smart card. If equipped with anexternal card reader and a communications link to a client host 3500 aPDA 3545 or cell phone 3550 may be used as a card reader 3535.Alternatively, the PDA 3545 and cell phone 3550 may be used without anexternal smart card. Additionally, cell phone 3550 may communicatedirectly with service provider servers 3515.

[0192] According to one embodiment of the present invention, client host3500 maintains a list of preferred service portals. A connection via aservice portal on the preferred list is attempted before connecting viaanother service portal.

[0193] Direct Access to Service Provider Servers

[0194] As mentioned previously, service provider servers require that auser be logged on. According to one embodiment of the present invention,the portal acts as an authority or single sign on service server in thatit performs user authentication and creates an authenticated logonmessage. According to one embodiment of the present invention, the logonmessage comprises a credential as described with reference to FIGS. 9Aand 9B. The logon credential is then returned to the user for subsequentuse as a single-sign-on token. The user may store the single-sign-ontoken on a personal device such as a smart card, cell phone or PDA. Thelogon credential or single-sign-on token enables the user to directlyaccess the service provider server. When needed for access to a server,the user activates access control on the PDA, smart card or cell phoneand sends the single-sign-on token to the service provider server. Theservice provider server may require additional user authentication,depending upon the type of service requested.

[0195] Turning now to FIG. 36, a flow diagram that illustrates a methodfor using federated identification servers and federated userauthentication servers using a randomized user identifier to gain accessto a service while maintaining privacy in accordance with one embodimentof the present invention is presented. At 3600, a randomized useridentifier is obtained. At 3605, a determination is made regardingwhether it is time to use the credential. When it is time to use thecredential, at 3610 the randomized ID is presented to a service portal.At 3615, a service portal sends a user authentication request to theidentity server federation that contains the randomized identifier. At3620, all servers in the identity server peer group search for a matchwith the randomized identifier. At 3625, a determination is maderegarding whether a match was found. If there is no match, an indicationis made at 3630. If there is a match, at 3635 matching entries from theidentity server federation are presented to a user authentication serverfederation to determine a single valid user data entry. Depending uponthe amount of user authentication required and the capabilities of eachuser authentication server, multiple user authentication servers maycooperate in providing the required user authentication.

[0196] According to one embodiment of the present invention, thefederated identity peer group is comprised of sub-groups and eachsub-group is assigned a priority value. A randomized ID is searched foraccording to sub-group priority. The sub-group having the highestpriority searches for a randomized ID first. If the randomized ID is notfound, the sub-group having the next-highest priority value performs thesearch.

[0197] Turning now to FIG. 37, a flow diagram that illustrates a methodfor using federated identification servers and federated userauthentication servers using a randomized user identifier to gain accessto a service while maintaining privacy in accordance with one embodimentof the present invention is presented. At 3700, a user enrolls for aservice. At 3705, a randomized ID is received in response to theenrolling. According to one embodiment of the present invention, aprinted randomized ID is received. According to another embodiment ofthe present invention, a barcode representing the randomized ID isreceived. At 3710, the randomized ID is stored. At 3715, a determinationis made regarding whether it is time to use the ID. When it is time touse the ID, at 3720 the randomized ID is used to obtain services.

[0198] A policy between the randomized ID creator and the randomized IDuser determines whether a randomized ID is valid. According to oneembodiment of the present invention, the randomized ID is valid for apredetermined amount of time. According to another embodiment of thepresent invention, the randomized ID is valid for a predetermined numberof uses. In other words, the ID may be used for a predetermined numberof times before it becomes invalid. Those of ordinary skill in the artwill recognize that other ID validity mechanisms are possible.

[0199] Referring again to FIG. 37, at 3725 a determination is maderegarding whether the ID is still valid. If the ID is still valid, theID is used beginning at 3715. If the ID is in the form of a barcode, itis used by scanning the barcode. If the ID is stored in a personaldevice such as a cell phone, PDA or smart card, the number iscommunicated from the personal device to the service provider Webserver. If the ID is no longer valid, a new ID is received at 3720 andit is used to obtain a service beginning at 3710.

[0200] Turning now to FIG. 38, a block diagram that illustratesenrolling with an identity server in accordance with one embodiment ofthe present invention is presented. At 3850, user 3825 communicates auser identity credential request to federated identity servers 3815,using either the client host 3800 directly, or by using the client host3800 via a personal device such as a smart card 3835, PDA 3840 or cellphone 3845. The user includes in the user identity credential request3850 data to be stored. The request may also include a preferred userauthentication mechanism and a quality of service (QoS) indicator.Federated identity servers 3815 verify the truthfulness, accuracy andcompleteness of the data to be stored according to the QoS indicator.The verification may include data authentication as described above. Theverification may also include user authentication.

[0201] Once the federated identifier servers 3815 have verified thedata, the federated identity servers 3815 enroll the user in one of thefederated user authentication services that may be requested to performone or more specific user authentication procedures to authenticate theuser in a future logon request. At 3855, the federated identity servers3815 return a user identity credential to the user 3825 via client host3800.

[0202] Before user 3825 uses service portal 3805 to obtain services onthe Web, the user 3825 must be authenticated. This is accomplished byusing the user identity credential and authenticated data in it. Thismay result in a service credential. User 3825 issues a service request,including a server group ID and the user identity credential. Theservice portal 3805 passes the identity credential to the federatedidentity server group indicated by the server group ID to authenticatethe user. The federated identity servers 3815 may delegate some or alluser authentication tasks to federated user authentication servers 3820.

[0203] According to one embodiment of the present invention, userauthentication includes issuing a challenge to a user's personal device(3835, 3840, 3845) directly from a federated user authentication server3820. According to one embodiment of the present invention, userauthentication includes issuing a challenge from a federated userauthentication server 3820 to a user's personal device (3835, 3840,3845) via a client host 3800.

[0204] According to one embodiment of the present invention, a responseto a challenge is communicated directly to the federated userauthentication server 3820 that issued the challenge. According toanother embodiment of the present invention, a response to a challengeis communicated via a client host 3800 to the federated userauthentication server 3820 that issued the challenge. According to oneembodiment of the present invention, the response to the challenge iscryptographically processed by a cell phone, smart card, PDA.

[0205] Once the user is authenticated, service portal 3805 returns alogon credential to the client 3825 via client host 3800. The user mayuse the logon credential to obtain services from service providers thatare accessible via the service portal 3805.

[0206] Turning now to FIG. 39, a block diagram that illustrates possiblecredential types in accordance with one embodiment of the presentinvention is presented. Reference numeral 3900 represents creating auser identity credential. A user identity credential comprises arandomized ID and the ID of an identification authority.

[0207] A user identity credential indicates a user has enrolled forsingle-sign-on services provided by a federation of user identityservers. Creating a user identity credential was described above withrespect to FIG. 38.

[0208] Once a user identity credential is obtained, a user may thenperform a logon process to create a logon credential 3905. A logoncredential 3905 may be stored as “Session ID cookie” on a client host. Alogon credential 3905 includes an indication of when the logoncredential will expire, and the client host IP address or any otherunique identifier, thus fixing a particular client host to a logoncredential and the user represented by the credential. A logoncredential is thus limited in time and place. Creating a logoncredential was described above with respect to FIG. 38.

[0209] A logon credential indicates a user is logged in through aparticular client host at a particular place. This enables securedelivery of proprietary or paid for information, or other content thatmust be delivered to the correct device. A logon credential may bestored on a client host because it is only valid when a user is workingon that client host.

[0210] A new dynamic user identity credential 3900 may be obtained inthe process of obtaining the logon credential 3905. It may be updatedwith additional user data and credentials 3910 in a reenrollmentprocess. Alternatively, the logon credential 3905 may be used to createa service credential.

[0211] A service credential is a one-time token for a session with aspecific server that may be obtained by applying a logon credential whenaccessing a service, while a logon credential may be used for multiplesimultaneous sessions for multiple service providers. A service providercreates a service credential for its own use. A service credential mayapplied to obtain further specific services, either for immediate use orfulfillment, or for postponed use or fulfillment. If the servicecredential is applied for immediate use of a service, a fulfillmentcredential 3925 may be dynamically created to satisfy the requested use.Reference numeral 3939 represents the consumption or use of thefulfillment credential, after which time the fulfillment credential canno longer be used and can be discarded.

[0212] If the service credential is applied to a service for later use,a rights key credential 3935 may be created. The entire rights keycredential may be stored on a secure client host or personal device.Alternatively, the rights key credential may be stored in a locker 3950and a locker access credential is created 3955 and then stored 3960 on asecure host or personal access device. In other words, the first methodstores the entire rights key credential on a secure device, while thesecond method stores or locks the entire rights key on a resource serversomewhere on the Web, and stores a key to the rights key on a securedevice. A Locker access credential is a special rights key credential,where the resources protected by the rights key are other credentials.

[0213] An exemplary use of a locker mechanism is as follows: A usershops a vendor Web site and purchases the rights to listen to aselection of music tracks for a year. A set of rights key credentials isused to store the rights purchased by the user and the rights keys areused later to access the resource(s) directly.

[0214] According to another embodiment of the present invention, any ofthe logon credential, service credential and fulfillment credential arecookies.

[0215] The process described with respect to FIG. 39 is not intended tobe limiting in any way. Those of ordinary skill in the art willrecognize that other credentials may be created for other purposes.Furthermore, credentials may be created using a sequence other than thatshown in FIG. 39.

[0216] Turning now to FIG. 40, a block diagram that illustrates using arandomized identifier for access to distributed resources whilemaintaining privacy in accordance with one embodiment of the presentinvention is presented. As shown in FIG. 40, user data is distributedamong multiple places. Access to resources owned by a user is protectedby one or more credentials. A credential includes a randomized ID,revealing nothing about the identity of the recipient. This search andmatch operation completely hides the identity of entity accessing thedata, thus preventing leaking information about the identity of the useropening or gaining access to the resource. Furthermore, having datadistributed over several peer groups ensures privacy because no singleentity can actually use the information each of these groups stores.

[0217] According to embodiments of the present invention, a userauthentication server federation performs user authentication onmatching entries from an identity server federation. The userauthentication server federation performs a sufficient level of userauthentication to support the required QoS. The user authentication mayreceive a credential supporting a first QoS, perform additional userauthentication and then return a credential supporting a higher levelQoS.

[0218] Turning now to FIG. 41, a flow diagram that illustrates a methodfor presenting a matching entry or entries from an identity serverfederation to a user authentication server federation to determine asingle valid user data entry in accordance with one embodiment of thepresent invention is presented. FIG. 41 provides more detail forreference numeral 3635 of FIG. 36. At 4100, for each user authenticationserver, a user record for the user that has been found by theidentification server is retrieved. At 4105, a determination is maderegarding whether the required QoS for user authentication can be met bythe current user authentication server. If the current userauthentication server cannot meet the required QoS, at 4110 a request ismade for one or more other cooperating user authentication servers toperform additional user authentication. If the current userauthentication server can meet the required QoS, at 4115 the client isengaged with using a challenge-response protocol or other protocol toobtain the required QoS. In this context, the term “QoS” is anindication of how much effort has been made by the user authenticationservers working together to establish that the user is actually presentat a terminal and intent on proceeding with the service request such as,by way of example, a purchase transaction. At 4120, the userauthentication credential is returned.

[0219] According to one embodiment of the present invention, userauthentication includes determining a cell phone number for a user andissuing a user authentication challenge to the user via the cell phone.The user authentication challenge may be, by way of example, a passwordchallenge.

[0220] According to another embodiment of the present invention, userauthentication includes the use of biometrics such as a retinal scan orfingerprint.

[0221] According to another embodiment of the present invention, userauthentication includes asking a smart card to engage in a cryptographicprotocol to confirm that the user has entered a PIN number for the card.

[0222] According to another embodiment of the present invention, theuser authentication includes asking a smart card to engage in a protocolto authenticate a user using biometrics stored on the card.

[0223] According to another embodiment of the present invention, anencrypted PIN pad is used to enter a PIN number for the card.

[0224] According to another embodiment of the present invention, userauthentication includes a combination of password/PIN and biometrics.

[0225] According to another embodiment of the present invention, theuser authentication server federation includes at least one userauthentication server that is specialized to perform a single type ofuser authentication. Having separate user authentication servers thatperform different functions enhances privacy because the data about anindividual is spread among multiple servers.

[0226] FIGS. 42A-46C illustrate embodiments of the present inventionthat use one or more credential to access data.

[0227] Turning now to FIG. 42A, a block diagram that illustrates datastored in a resource server in accordance with one embodiment of thepresent invention is presented. As shown in FIG. 42A, a resource serverstores resources 4200 and associated rights key credential identifiers.A resource may be, by way of example, access to a Web page or audiotrack. Each rights key credential includes one or more cryptographickeys that allow access to the associated resource. Thus, the identifiers4205 are identifiers of credentials that give access to a resource.

[0228] When a user wants to use a resource, the user presents a rightskey credential and a request for a resource to a resource server. Theresource server finds a resource matching the rights key credential.Rights keys in the credential are used to open or gain access to theresource.

[0229] According to one embodiment of the present invention, the entirerights key credential is stored on a secure device. According to anotherembodiment of the present invention, the credential ID is stored in asecure device and the rest of the rights key credential is storedseparately.

[0230] One example use of this embodiment is where the resource isrequested by a third party (such as a merchant accessing user data) thatis not the owner but has permission of the owner to access the resource.In this case, it is possible that when the resource owner enrolls, theresource owner may authorize the third party to access the owner'scredential and copy it into the third party's credential mechanism, thusproviding the third party with indirect access to the resource protectedby the credential. A second rights key ID may be associated with theresource referring to the rights key credential held by the owning user.

[0231] Turning now to FIG. 42B, a block diagram that illustrates datastored in a resource server in accordance with one embodiment of thepresent invention is presented. FIG. 42 is similar to FIG. 42A, exceptthat FIG. 42B includes references to one or more cryptographicprotection mechanism 4220 that are available for use to provide acryptographic protection when delivering the resource content to theuser.

[0232] Turning now to FIG. 43A, a block diagram that illustratesobtaining a resource from a resource server in response to a resourcerequest including a set of rights keys in accordance with one embodimentof the present invention is presented.

[0233] Turning now to FIG. 43B, a block diagram that illustratesobtaining a resource from a resource server in response to a resourcerequest including a set of rights keys and a reference to a deliveryprotection mechanism and optionally a target device in accordance withone embodiment of the present invention is presented. According to thisembodiment, resources are delivered to the client host or the optionallyprovided target device under protection of the referenced cryptographicmechanism.

[0234] Turning now to FIG. 43C, a block diagram that illustrates arights key credential in accordance with one embodiment of the presentinvention is presented. The credential data field 4365 and the sealedcredential data field 4370 include cryptographic key data. Public keysmay be stored in the credential data field 4365, while secret keys arestored in the sealed credential data field 4370. Nested credentials 4375may refer to credentials that relate to a resource delivery mechanism.For example, a user with a credential that entitles the user to play anMP3 file may indicate a connection should be made directly with a clientdevice such as an MP3 player via an infrared connection to a clienthost. This increases user control over the use of remotely-storedresources.

[0235] Turning now to FIG. 44, a flow diagram that illustrates a methodfor obtaining access to a resource in accordance with one embodiment ofthe present invention is presented. At 4400, a resource server is sent aresource request that includes a rights key credential. At 4405, theresource server matches the key with an identifier in a set ofidentifiers associated with a resource. At 4410, a determination is maderegarding whether a new ID must be created. If a new ID must be created,it is created at 4415. If in this case, the ID is returned to the user.At 4420, the resource found at 4405 is returned.

[0236] Turning now to FIG. 45, a flow diagram that illustrates a methodfor obtaining access to a resource requiring multiple keys in accordancewith one embodiment of the present invention is presented. Multiple keysmay be used, by way of example, when the owner of a resource and theentity requesting the resource are different entities. At 4500, aresource server is sent a resource request that includes a first rightskey credential and a second rights key credential. At 4505, the resourceserver matches both keys with identifiers in a set of identifiersassociated with a resource. At 4510, a determination is made regardingwhether a new ID must be created. None, one or both of the IDs may needto be created. If a new ID must be created, it is created at 4515. At4520, the resource found at 4505 is returned.

[0237]FIG. 46A is a block diagram that illustrates a Universal ResourceLocator (URL) that includes a rights key credential to access a specifickind of resource stored on a server in a resource server peer group inaccordance with one embodiment of the present invention. As shown inFIG. 46A, the URL 4600 includes a resource server peer group 4620, aresource directory for a particular type of resource 4625, and therights key for the resource 4630.

[0238]FIG. 46B is a block diagram that illustrates a Hypertext TransferProtocol (HTTP) message that includes rights key credential data inaccordance with one embodiment of the present invention.

[0239]FIG. 46C is a block diagram that illustrates a smart card thatincludes a rights management applet in accordance with one embodiment ofthe present invention.

[0240]FIGS. 46D, 47 and 48 illustrate embodiments of the presentinvention that use approximated user data to obtain services for a userin a manner that is privacy-sensitive.

[0241] For the purposes of the present disclosure, the term“Aggregation” refers to transforming specific user data into lessspecific and thus more approximate user data and the term “Aggregationauthority” refers to an authority that performs this function.Aggregation includes obtaining information about a user that is notexact. For example, a service provider might store the number of timesany Web page with a certain attribute was accessed, instead of storingthe Web page URL or the Web page itself.

[0242] An aggregation authority may be classified in terms of theaggregation policies the authority applies. An external aggregationauthority applies publicly accepted aggregation policies. A peeraggregation authority applies aggregation policies shared with anotherpeer aggregation authority. An internal aggregation authority appliesits own private aggregation policies. A peer group authority mayrestrict access to its policies to its peers.

[0243] Aggregation itself may be static or dynamic. The term “staticaggregation” refers to performing aggregation based only uponuser-provided information. An aggregation authority receivesuser-provided information, applies an aggregation policy to theuser-provided data and returns approximated user data to the user.

[0244] The term “dynamic aggregation” refers to performing aggregationbased upon both user-provided information and local information gatheredabout the user during an interaction with a service. In dynamicaggregation, a service provider receives user data from a user. Theservice provider also stores and gathers its own information about theuser. The service provider presents both types of user data to anauthority. The aggregation authority applies an aggregation policy tothe combined data to obtain new approximated user data and returns thenew approximated user data to the service provider.

[0245] Turning now to FIG. 46D, a block diagram that illustrates dynamicaggregation of user data in accordance with one embodiment of thepresent invention is presented. FIG. 46D includes a user 4645, a firstvendor Web site 4635, a second vendor Web site 4640 and an authority4630. The user 4645, shops at first vendor Web site 4635 and secondvendor Web site 4640. The vendors (4635, 4640) communicate with theauthority 4640. To obtain approximated user data based on more specificuser data such as user activity at the vendor Web site. The approximateduser data becomes part of the user data that the user retains for usewhen visiting other Web sites. According to one embodiment of thepresent invention, the user data is stored in secure user data storage.

[0246] In more detail, at 4650 a user 4645 presents a user profile to afirst book vendor 4635. The first book vendor 4635 collects informationabout the type of books viewed or purchased using the first bookvendor's Web site. By way of example, the book vendor 4635 may note theuser purchased a number of science fiction novels and a number ofgardening books. At 4655, the book vendor presents this collected userdata and the user profile obtained from the user 4645 to an authority4630. The authority applies an aggregation policy to the user profileand the collected user data to obtain approximated user data. By way ofexample, one possible aggregation policy may be to rate a user interestin book categories, using a commonly accepted set of categories. If theuser data indicate the user 4645 is interested in neither sciencefiction nor gardening, and if the collected user data indicates the user4645 recently purchased ten books in each category from book vendor4635, the user data is modified to include a rating of the user'sinterest in these two categories.

[0247] Still referring to FIG. 46D, at 4670 the user 4645 maysubsequently shop at a second book vendor Web site. The user 4640presents a user profile including the approximated user data createdwhen the user visited the first vendor 4635 Web site. The second bookvendor 4640 may use the approximated user information to tailor theuser's experience while shopping at the second Vendor Web site. Thesecond book vendor 4640 may also collect information about the type ofbooks viewed or purchased using the second book vendor's Web site,present this information to the authority 4630 and receive updatedapproximated user data, using a process similar to that which wasdiscussed with respect to the first vendor 4635.

[0248] Turning now to FIG. 47, a flow diagram that illustrates a methodfor dynamic aggregation of user data in accordance with one embodimentof the present invention is presented. At 4700, a service providerreceives a service request and associated user data. At 4705, userprofile information is collected. At 4710, the user data and userprofile information or a reference to the information is presented to anauthority. At 4715, the service provider receives approximated userinformation from the authority. At 4720, the approximated userinformation is returned to the user.

[0249] Turning now to FIG. 48, a flow diagram that illustrates a methodfor static aggregation of user data in accordance with one embodiment ofthe present invention is presented. At 4800, user data is received. At4805, an aggregation policy is applied to the user data to obtainapproximated user data. At 4810, the approximated user data is returnedto the user.

[0250] According to one embodiment of the present invention, aggregateduser data is stored in a credential. According to another embodiment ofthe present invention, a profile includes one or more credentials thatin turn include aggregated user data. A profile is thus a form ofaggregation of information about a user. According to another embodimentof the present invention, part of the data in the profile is bit-mapped.

[0251] Aggregation is privacy-protecting because the information storedis not exact. Therefore, it reveals nothing about a user as anindividual. Any user could be described using approximated userinformation without revealing the user's identity. Furthermore, themechanism for compiling the information may be hidden.

[0252] Turning now to FIG. 49, a block diagram that illustrates using asmart card to securely store and reconfigure cookies in accordance withone embodiment of the present invention is presented. As shown in FIG.49, a computer 4930 is equipped with a card reader 4935 for receiving asmart card 4940. The computer 4930 may be connected to a network 4920that communicates with a plurality of other computing devices, such as aWeb server 4900. Web server 4900 includes cookie-processing logic 4915,reconfigured cookies 4910 and at least one secret 4905 shared withapplet 4945 on smart card 4940. Smart card 4940 also includescookie-processing logic 4960 and storage for at least one cookie 4955.

[0253] In operation, Web Server 4900 issues a cookie request that isreceived by computer 4930. If the requested cookie is on the smart card4940 and if the cookie comprises a dynamic cookie, cookie-processinglogic 4960 uses the shared secret 4940 to reconfigure the cookie bitpattern and the reconfigured cookie is sent to Web server 4900 viacomputer 4930. Cookie-processing logic 4915 on Web server 4900 receivesthe reconfigured cookie and determines whether the cookie needs to bereconstructed. If the cookie needs to be reconstructed,cookie-processing logic 4915 reconstructs the cookie using shared secret4905. Because cookies are reconfigured before being sent, a packetsniffer 5025 or similar device cannot match cookie data with aparticular user.

[0254] According to one embodiment of the present invention, a cookie isassociated with a timestamp. If the timestamp indicates the cookie isstale, the cookie is not processed.

[0255] According to another embodiment of the present invention, allcookies on a card are static, thus obviating the need for shared secrets(4905, 4950).

[0256] According to another embodiment of the present invention, acookie management credential specifies the type of cookie management tobe performed.

[0257] Turning now to FIG. 50, a block diagram that illustrates using asmart card to securely store and reconfigure cookies in accordance withone embodiment of the present invention is presented. FIG. 50 is similarto FIG. 49, except that the secret 5065 resides only on Web server 5000and is not shared with smart card 5040. Additionally, cookie updatelogic (5005, 5050) is used to periodically update cookies on the smartcard 5040.

[0258] Turning now to FIG. 51, a flow diagram that illustrates a methodfor browsing the World Wide Web (WWW) in accordance with one embodimentof the present invention is presented. At 5100, the card is placed in acard reader. At 5135, a browser accesses a Web site. At 5140, adetermination is made regarding whether a cookie is needed. If a cookieis needed, the browser requests a cookie from the card at 5145. At 5105,the card receives the cookie request and determines whether the card hasa cookie matching the request. If the card has a cookie matching therequest, at 5110 a determination is made regarding whether the user hasenabled the card to return cookies for the request such as entering aPIN. If the card has enabled cookies for the request, at 5115 adetermination is made regarding whether the cookie is dynamic. If thecookie is dynamic, the cookie bit pattern is reconfigured at 5120 andthe reconfigured cookie is returned at 5125. If the cookie is static,the cookie is returned without reconfiguring it at 5125. If the carddoes not have a cookie matching the request or if the user has notenabled cookies for the request, an indication that no cookie will bereturned is returned at 5130.

[0259] At 5150, the browser makes a determination regarding whether acookie was returned from the card. If no cookie was returned from thecard, a cookie is obtained from off the card, such as a local harddrive, and the cookie is sent to the server at 5160.

[0260] If a cookie was returned from the card, the cookie from the cardis sent to the server at 5160. At 5165, the server determines whether acookie was returned from the browser. If no cookie was returned from thebrowser, the process terminates at 5185. If a cookie was returned fromthe browser, at 5170 a determination is made regarding whether thecookie needs to be reconstructed. If the cookie needs to bereconstructed, it is reconstructed at 5175 and used at 5180. If thecookie does not need to be reconstructed. In either case, it is used at5180.

[0261] Embodiments of the present invention have a number of advantages.Service providers can exchange information about a person withoutrevealing inappropriate or unnecessary information, thus businesstransactions may be conducted over an open network such as the Internetwhile maintaining privacy.

[0262] While embodiments and applications of this invention have beenshown and described, it would be apparent to those skilled in the arthaving the benefit of this disclosure that many more modifications thanmentioned above are possible without departing from the inventiveconcepts herein. The invention, therefore, is not to be restrictedexcept in the spirit of the appended claims.

What is claimed is:
 1. A method for obtaining a service on a datacommunications network, the method comprising: enrolling with anauthority, said enrolling creating enrollment results, said enrollmentresults comprising user data; and using said enrollment results toobtain a service from a service provider, said service provider capableof communicating with said authority to verify said enrollment results.2. A method for managing identification in a data communicationsnetwork, the method comprising: generating authenticated user data, saidgenerating comprising: presenting a request for authenticated user dataand a first set of user data to an authority; and receivingauthenticated user data from said authority in response to said request;and using said authenticated user data to obtain at least one service onsaid data communications network, said using comprising: presenting aservice request, said authenticated user data to a service provider; andreceiving said at least one service in response to said service requestif said service provider determines said authenticated user data issufficient to provide said at least one service.
 3. A program storagedevice readable by a machine, embodying a program of instructionsexecutable by the machine to perform a method for obtaining a service ona data communications network, the method comprising: enrolling with anauthority, said enrolling creating enrollment results, said enrollmentresults comprising user data; and using said enrollment results toobtain a service from a service provider, said service provider capableof communicating with said authority to verify said enrollment results.4. A program storage device readable by a machine, embodying a programof instructions executable by the machine to perform a method formanaging identification in a data communications network, the methodcomprising: generating authenticated user data, said generatingcomprising: presenting a request for authenticated user data and a firstset of user data to an authority; and receiving authenticated user datafrom said authority in response to said request; and using saidauthenticated user data to obtain at least one service on said datacommunications network, said using comprising: presenting a servicerequest, said authenticated user data to a service provider; andreceiving said at least one service in response to said service requestif said service provider determines said authenticated user data issufficient to provide said at least one service.
 5. An apparatus formanaging identification in a data communications network, the apparatuscomprising: means for generating authenticated user data, saidgenerating comprising: means for presenting a request for authenticateduser data and a first set of user data to an authority; and means forreceiving authenticated user data from said authority in response tosaid request; and means for using said authenticated user data to obtainat least one service on said data communications network, said means forusing comprising: means for presenting a service request, saidauthenticated user data to a service provider; and means for receivingsaid at least one service in response to said service request if saidservice provider determines said authenticated user data is sufficientto provide said at least one service.
 6. An apparatus for managingidentification in a data communications network, the apparatuscomprising: means for receiving a user-controlled secure storage device;means for enrolling said user with an authority, said enrollingcomprising providing information requested by said authority; means forreceiving user data in response to said enrolling; means for storingsaid user data in said user-controlled secure storage device; and meansfor using said user data at a service provider Web site to obtain aservice.
 7. An apparatus for obtaining a service on a datacommunications network, the apparatus comprising: an enrollmentauthority configured to accept an enrollment request, said enrollmentauthority further configured to return enrollment results in response tosaid enrollment request, said enrollment results comprising user data,said enrollment results for use in obtaining a service from a serviceprovider.
 8. An apparatus for obtaining a service on a datacommunications network, the apparatus comprising: a service providerconfigured to accept a service request and enrollment results obtainedfrom an enrollment authority, said service provider capable ofcommunicating with said authority to verify said enrollment results,said service provider configured to provide said service based upon saidenrollment results and a response from said enrollment authority.
 9. Anapparatus for managing identification in a data communications network,the apparatus comprising: an authority configured to accept anauthenticated data request and a user data, said authority furtherconfigured to authenticate said user data to create authenticated data,said authority further configured to return said authenticated data inresponse to said authenticated data request.
 10. An apparatus formanaging identification in a data communications network, the apparatuscomprising: a service provider configured to accept a service request, afirst set of user data and a second set of user data, said first set ofuser data comprising user data authenticated by an authority, saidservice provider further configured to determine whether said first setof user data and said second set of user data are sufficient to providesaid service, said service provider further configured to provide saidservice based upon said determination.